Virtual IP 的实现原理

什么是VIP？

VIP即Virtual IP Address，是实现HA（高可用）系统的一种方案，高可用的目的是通过技术手段避免因为系统出现故障而导致停止对外服务，一般实现方式是部署备用服务器，在主服务器出现故障时接管业务。 VIP用于向客户端提供一个固定的“虚拟”访问地址，以避免后端服务器发生切换时对客户端的影响。

例如在下图的系统中，采用了三个服务器的集群来实现服务的高可用，后端服务器集群通过VIP 193.168.0.6对外提供服务，客户端只知道VIP，并不关注后端服务器的真实地址。

VIP被加载在Master的网卡上，所有指向VIP的请求会被发向Master，Slave服务器出于Standby状态。如果Master出现故障，集群会通过选举算法从可用的Slave节点中选出一个新的Master节点，并将VIP也迁移到新Master节点的网卡上。这样可以保证服务始终可用，并且对客户端来说访问的IP也不会变化。

注意VIP始终指向一个Master，因此VIP的方案并不能实现LB，只能实现HA。

______________________
|                      |
| VIP: 193.168.0.6     |
|-----| Host IP: 193.168.0.2 |
|     | Role: Master         |
|     |______________________|
|
|      ______________________
|     |                      |
|     | VIP: Unassigned      |
Public ----(example.com = 193.168.0.6)--|-----| Host IP: 193.168.0.3 |
|     | Role: Slave          |
|     |______________________|
|
|      ______________________
|     |                      |
|     | VIP: Unassigned      |
|-----| Host IP: 193.168.0.4 |
| Role: Slave          |
|______________________|

VIP的实现原理

Master选举：集群创建或者Master出现故障时，集群通过选举协议得到一个Master作为对外服务的节点
配置VIP： HA软件将VIP配置到Master节点的网卡上
ARP广播：主动对外广播ARP消息，声明VIP对应的MAC地址为Master的网卡MAC地址

通过arp -a 命令查看193.168.0.6对应的MAC地址和193.168.0.2相同

1
2
3

arp -a|grep 193.168.0
? (193.168.0.6) at fa:16:3e:2a:7e:d4 [ether] on br-apidefault
? (193.168.0.2) at fa:16:3e:2a:7e:d4 [ether] on br-apidefault

登录到193.168.0.2主机上，使用ip addr命令可以看到网卡上绑定了VIP 193.168.0.6

ip addr
10: br-apidefault: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether fa:16:3e:2a:7e:d4 brd ff:ff:ff:ff:ff:ff
inet 193.168.0.3/16 brd 193.168.255.255 scope global br-apidefault
valid_lft forever preferred_lft forever
inet 193.168.0.6/16 brd 193.168.255.255 scope global secondary br-apidefault
valid_lft forever preferred_lft forever

采用Keepalived实现VIP

Keepalived的设计目的即是为了管理VIP，因此使用Keepalived实现VIP的配置非常简单。Keepalived采用了Virtual Router Redundancy Protocol (VRRP)协议来进行实现主备服务器之间的通信以及选举。

下面介绍如何采用Keepalived配置一个两节点的HA集群。

首先将用于设置VIP的脚本放到主备两个服务器的 /etc/keepalived/notify.sh 路径下

#!/bin/bash
vipAddress="192.168.121.100/24"
if [[ "x$1" == "xmaster" ]]; then
ip address add dev eth1 ${vipAddress}
else
ip address del dev eth1 ${vipAddress}
fi

Master节点的Keepalived配置文件 keepalived.conf

vrrp_instance VI_1 {
state MASTER
interface eth0
garp_master_delay 10
smtp_alert
virtual_router_id 51
priority 100
vrrp_unicast_bind 192.168.121.51
vrrp_unicast_peer 192.168.121.52
advert_int 1
authentication {
auth_type PASS
auth_pass testpass
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
}

Backup节点的Keepalived配置文件 keepalived.conf

vrrp_instance VI_1 {
state BACKUP
interface eth0
garp_master_delay 10
smtp_alert
virtual_router_id 51
priority 50
vrrp_unicast_bind 192.168.121.52
vrrp_unicast_peer 192.168.121.51
advert_int 1
authentication {
auth_type PASS
auth_pass testpass
}
notify_master "/etc/keepalived/notify.sh master"
notify_backup "/etc/keepalived/notify.sh backup"
}

采用pacemaker实现VIP

Pacemaker和Keepalived的定位不同，Keepalived一般用于无状态，可以Active-Active的HA集群；而Pacemaker可以实现有状态，Active-Passive的HA集群。例如采用pacemaker可以将服务状态和数据从出现故障的服务器上迁移到备份机上，例如拷贝配置文件，加载数据库等。因此Pacemaker的内部结构和配置比Keepalived的更复杂。

Packemaker包括下列组件：

Cluster Information Base (CIB) 集群信息库：使用XML保存了集群内部的配置和当前状态，CIB保存的内容在集群内保持同步。
Policy Engine (PEngine or PE)：策略引擎：当集群中有节点宕机导致资源当前状态和理想状态不一致时，策略引擎使用CIB中的信息计算需要执行哪些动作使集群达到应处于的理想状态。
Cluster Resource Management daemon (CRMd)：集群资源管理守护进程：集群选举一个CRMd为Master，由Master通过集群消息系统将策略引擎的指令发向本地的LRMd或者集群中的其他CRMd执行。
Local Resource Management daemon (LRMd)：本地资源管理守护进程
Fencing daemon (STONITHd): 爆头守护进程： Shoot the other node in the head,在某些情况下，可能有必要关闭节点，以保护共享数据或完整的资源回收。为此，Pacemaker配备了stonithd设备。STONITH可以将其它节点“爆头”，通常是实现与远程电源开关。
cluster abstraction layer下面为集群的底层消息系统。

采用Pacemaker实现VIP的原理和Keepalived基本相同，也是采用将VIP作为Secondary IP绑定到Master网卡的方式，具体设置步骤略。

人生苦短，我用python